Participants in networked communications environments sometimes need to communicate with one another, such as to exchange requests and responses containing results of the requests. Participants are applications, users, and generally any entity that uses communications services provided by the networked communications environment. As an example, a client participant (e.g., an application executing on a computing device) may send requests for services to a server participant (e.g., a network service or application executing on another computing device). The server participant may send to the client participant a response containing results of the service request. An endpoint is a device or software that represents a participant in the networked communications environment. Each participant can have multiple endpoints through which it can send and receive communications. As an example, a user or application can use a mobile computer as an endpoint as well as a desktop computer as an endpoint. The participants employ a source endpoint to send communications to a target endpoint and employ a target endpoint to receive communications sent by a source endpoint.
The endpoints may employ various mechanisms to communicate messages containing requests and responses, such as a Session Initiation Protocol (“SIP”). SIP is an application-layer control protocol that endpoints can use to discover one another and to establish, modify, and terminate communications sessions. SIP is an Internet-proposed standard. Its specification, “RFC 3261,” is available at the Internet Engineering Task Force's web site (www.ieff.org). This specification is incorporated herein in its entirety by reference. An exchange of messages during a SIP session is generally referred to as a dialog. SIP may use lower-level communications layers to transport a dialog's messages, such as Transmission Control Protocol/Internet Protocol (“TCP/IP”), which are commonly employed transport- and network-layer protocols.
Some participants support parallel requests whereas others support requests serially. When a server participant supports parallel requests, it can receive multiple requests even though it has not serviced (e.g., responded to) an earlier request. In contrast, when a server participant supports requests serially, it needs to respond to an earlier request before processing a subsequent request. Client participants may have insufficient information to determine whether to wait for a response to a request before sending another request or to send all pending requests and await multiple responses. As an example, a client participant provided by a vendor that sends a request to a server participant may need to send multiple requests to a server participant provided by another vendor. When requests can be sent in parallel, responses may be received in a timely manner.